[Split 1/3] Restructure modules: java/android → core/core-android under io.ably.pubsub - #1232
[Split 1/3] Restructure modules: java/android → core/core-android under io.ably.pubsub#1232umair-ably wants to merge 1 commit into
Conversation
…e/core-android Applies the first step of PDR-091b to this repo: the shared implementation becomes the new internal core artifacts, published under the io.ably.pubsub group at the new 2.0.0 major. - The `java` module becomes `core`, publishing io.ably.pubsub:core (jar). - The `android` module becomes `core-android`, publishing io.ably.pubsub:core-android (aar). - GROUP moves to io.ably.pubsub and VERSION_NAME to 2.0.0 for everything this repo publishes (liveobjects, pubsub-adapter and network-client-* move group alongside, per the rollout plan). - Both core POMs state explicitly that they are internal implementation artifacts for Ably's own device/server packages, not for direct use. - liveobjects, pubsub-adapter, uts and examples retarget their project dependencies; CI workflows, CONTRIBUTING and the uts README follow the new task paths. The io.ably:ably-java and io.ably:ably-android artifacts are never published from this branch again; 1.x fixes ship from a maintenance branch per PDR-091b. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
So is the idea here that, if I'm using java on a server say, I now need two artifacts: |
afaict, you declare one dependency, |
That's true, but why is it necessary? What's the problem with having a single server artifact that contains the server and core java packages? |
2 participants
First of a stack of PRs applying PDR-091b (PubSub device/server package split, major releases) to this repo, targeting the long-lived
integration/v2branch. Reference implementation: ably-js#2293.What this PR does
java→core: publishesio.ably.pubsub:core(jar, JVM) — wasio.ably:ably-java.android→core-android: publishesio.ably.pubsub:core-android(aar) — wasio.ably:ably-android.GROUP=io.ably.pubsub,VERSION_NAME=2.0.0: everything the repo publishes moves to the new group and major in lockstep (liveobjects,pubsub-adapter,network-client-*ride along, per the rollout plan).liveobjects,pubsub-adapter,uts,examplesretargetproject(":java"/":android")→":core"/":core-android";integration-test.yml,emulate.yml,javadoc.yml, CONTRIBUTING.md and uts/README.md follow.git mvfor the module directories — history follows.What this PR deliberately does not do
io.ably.pubsub:device/io.ably.pubsub:serverland in the next PR in the stack.ably-java/<version>base agent identifier (matching ably-js, whose core keepsably-js/<version>); side-declaring agents are stamped by the door packages (next PR).io.ably:ably-java/io.ably:ably-android1.x are never published from this branch; fixes ship from a maintenance branch cut before the integration merge.Notes for reviewers
io.ably.lib.*) is unchanged in the cores for now — the namespace decision (new pubsub root package vs. documented classpath-collision hazard) and theRest*→Http*pass are deliberately sequenced later on the integration branch.core-android/src/main/resources/META-INF/io/ably/ably-android/verification.propertiesstill carries the verification token issued forio.ably:ably-android— a new token for the new artifact id needs requesting before GA (tracked in the rollout plan).deploy/check-archives.shwas already stale (greps abuild.gradlethat no longer exists); untouched here.Verified locally:
checkWithCodenarc checkstyleMain checkstyleTest runUnitTests runLiveObjectsUnitTests :uts:runUtsUnitTestsgreen;:core-android:compileReleaseJavaWithJavacgreen;publishToMavenLocalproduces the expectedio/ably/pubsub/{core,core-android,liveobjects,pubsub-adapter,network-client-*}/2.0.0coordinates.🤖 Generated with Claude Code